Radio frequency identification (RFID) device implementation projects for the enterprise level may be highly complex and require relatively major shifts in processes and procedures enterprise wide. Typically, RFID devices are installed throughout an enterprise for tracking a variety of items, products and people. Further, RFID devices may be used by an enterprise throughout the distribution system, and potentially into the point of use/consumption. Examples of RFID devices include fixed readers, label printers, handheld readers, and cell phones, among others, that have an antenna designed to emit a radio frequency that allows for reading information on RFID tags. These RFID devices may also include other, optional accessories, such as, for example, barcode readers or keypads that may capture additional data when a reads of an RFID tag occurs.
The enterprise, such as, for example, the information technology department of the enterprise, is often tasked with figuring out how to get hundreds to thousands of RFID devices to communicate regionally, if not globally, to a central location, such as, for example, the headquarters of the enterprise. However, this process may be one of the more expensive aspects of deploying an RFID solution. In some uses, the RFID hardware may use a Low Level Reader Protocol (LLRP) to communicate RFID tag information. However, not all RFID devices may support LLRP. Thus, RFID systems may require the use of middleware software that assists in allowing the RFID device to communicate with the software of the RFID system. However, the need for such middleware software, which may be purchased or built, for the RFID system may increase the cost, maintenance and/or complexity of the RFID system.
Additionally, RFID systems typically require a hardware and networking infrastructure that allows the RFID devices to be able to communicate with business application servers. For example, RFID systems that receive information or data from RFID devices that may need to be accessible so that the data contained therein may be acted upon by the business applications, such as, for example, in an enterprise resource planning (ERP) system. Thus, developers of RFID systems may be tasked with not only figuring out how to handle the desired RFID data, but also other events and processes involving the RFID data. Additionally, developers of such RFID systems may need to account for a variety of other issues, such as, for example, management of remote firmware, RFID device health, and the health of any peripherals connected to the RFID device. Further, business processes throughout an organization that utilize the RFID system may need to be, concurrently, updated for the new tracking ability that new, updated or modified software may provide. The infrastructure for an RFID system may also need to be built in conjunction with the associated business software that utilizes data obtained by, or communicated through the use of, the RFID system, which may introduce another cost and/or delay point. In view of the foregoing, projects to implement RFID systems often never get off the ground due to the time and monetary investment in pure infrastructure costs.
RFID devices currently typically have an application programming interface (API) that is only useful for local area network (LAN) segments. Thus, a local server connects to the RFID device via the API and then manages the functions of the RFID device, such as, for example, RFID scans, reboots of the RFID device, the health of the RFID device, and, potentially, firmware upgrades. However, the API cannot be accessed over the Internet. Some RFID devices may have their own API that is either based on a proprietary protocol or an open source standard such as LLRP. Such protocols, however, are typically designed for LAN communications only.
A typical setup of an RFID system has a server on the same LAN network as the RFID device(s). The server may connect to the RFID device(s) and then control their functionality. Control of the RFID device by the server is typically done over a specific transmission control protocol (TCP) port, such as, for example, TCP port number 5084 for LLRP. However, if a server needs to connect to an RFID device(s) that is on a different LAN network, then either a virtual private network (VPN) is required to bridge the different networks or a route over the internet with a firewall forwarding rule needs to be in place to make the connection between the different servers.
Other RFID devices are dependent on being connected to a computer to operate or are built into a computer, such as, for example, a handheld barcode scanner. In these instances, the server may connect to the computer, or the computer may be pushing data to the server. However, if the server needs to connect to the computer, the same problems exist for communications across different networks.